@mrbean-bremen Let me know what you think here. I’ve been testing this specific branch in the context of 3D Slicer/CommonTK and have had success.

The CommonTK based CMake external project for building:
https://github.com/jamesobutler/CTK/blob/1d55f252926477b3de0d2454e85da56f6128cee8/CMakeExternals/PythonQt.cmake#L146-L167

Would Mevislab adopt CMake for PythonQt building at some point too? 3D Slicer and CommonTK has been a fully CMake build system for over a decade and Qt 6 switched to building with CMake as well.

Thanks for this!

Would Mevislab adopt CMake for PythonQt building at some point too?

We actually use CMake to build PythonQt for a few years now, albeit our implementation may not be generic enough.
We had been discussing merging this back, and IIRC, @jcfr at the time had volunteered to merge the Slicer version upstream instead, so we decided to wait for this.
I will leave the actual review to @usiems, who was involved in the switch to CMake in the first place.

As for the CI builds - I also think that in the long run we can remove the qmake jobs, at least for newer versions of Qt.

We actually use CMake to build PythonQt for a few years now, albeit our implementation may not be generic enough.

That's great to hear as we will then have more people supporting the CMake build infrastructure here.

As for the CI builds - I also think that in the long run we can remove the qmake jobs, at least for newer versions of Qt.

Yeah all the various jobs was definitely starting to get confusing to me because there were say Windows jobs from the build.yml workflow as well as build_latest.yml and I wasn't sure why both existed. Then the Windows CMake jobs just added more on top of that.

Is there also still a need to support older Qt versions such as 5.9 and 5.11 in the latest main branch? Or can we support only Qt 5.15+ (aka supporting folks jumping to Qt6 from Qt 5.15)? There are always the older tags of PythonQt that will be forever around and unchanging so it is not like the code is disappearing. That would help reduce the complexity around the testing matrix of latest code.

Is there also still a need to support older Qt versions such as 5.9 and 5.11 in the latest main branch?

From my perspective no (@he-hesce may disagree though 😀).

We need support for Qt 5.9 which is in use on RHEL 7. However, as RHEL 7 is using Python 2.7, we are stuck on PythonQt 3.6.1 until RHEL 7 can be retired (~3-4 years). Then we can upgrade to PythonQt 4.x series. Qt 5.15 is what is used on RHEL 9 which means that in the 4.x series, we only need support for Qt 5.15.

We would like that if possible that PythonQt kept qmake support in parallel with cmake support as we build PythonQt as part of our code base which uses Qt 5.15 and qmake which makes things nice and integrated without having to support/use another build system (cmake) from within qmake. I think it would be a good idea to support qmake as long as Qt 5.15 is supported.

We can of course still get stuck on some specific 4.x revision eventually. It's likely we will be using Qt 5.15 for another 9 years at least as we need to support RHEL 9 until 2035 if not beyond the official EOL. We won't be moving to Qt 6.x (and thus cmake) until we move on to RHEL 10/11 and can drop support for RHEL 9/Qt 5.15 (so around 2035-2038).

We prefer to use a single PythonQt version on all supported platforms as it makes building, testing, and deployment easier. Obviously I do understand that our needs cannot dictate overall PythonQt project policy and I appreciate the backward compatibility which exist so far.

Our active support matrix for our scientific geophysical visualization software using PythonQt 3.6.1 on all platforms:

• RHEL 7 - Python 2.7 - Qt 5.9 - EOS (End of Support) 2030;
• RHEL 8 - Python 3.6 - Qt 5.15 - EOS 2033;
• RHEL 9 - Python 3.9/3.11/3.12 - Qt 5.15 - EOS 2038;
• Ubuntu 22.04 LTS - Python 3.10 - Qt 5.15 - EOS 2028;
• Ubuntu 24.04 LTS - Python 3.12 - Qt 5.15 - EOS 2030.

For @he-hesce's use case it seems like creating a 4.0 branch to serve as an LTS for over a decade of support seems reasonable. @mrbean-bremen Maybe you can make this maintenance branch based off the v4.0.1 tag? There appears to already have been some maintenance branch's like this such as 3.2 and 3.0. It is not that @he-hesce 's application will never switch to Qt6 or CMake, but just far in the future. So the main branch developers could continue with consolidating on a single build system and optimizing it with the help of the MeVisLab and Slicer community and @he-hesce could help maintain the 4.0 branch for LTS support until jumping to a new LTS branch far in the future. The LTS branches would represent absolute minimal changes based on the apparent desire to not make changes unless absolutely necessary.

@jamesobutler: Sounds good.

I think for me, as PythonQt is "feature complete", a stable LTS branch would best be supported by ensuring newer Qt 6.x and Python 3.x releases are working (while not breaking older releases) as we don't know yet what Qt 6.x and Python 3.x will be the LTS-supported ones on RHEL 11 and Ubuntu 26.04 LTS and beyond. On RHEL 10, it appears they are currently supporting Qt 5.15/6.9 and Python 3.12 (thus making Qt 5.15 supported by RHEL until 31 May 2038 [!] and thus supported in our product until 2041).

Thus backporting compatibility fixes from the main branch to LTS branches would be a good idea I think. Other than fixing critical/show-stopper bugs which are found (though these seem rare).

Thus backporting compatibility fixes to the main branch to LTS branches would be a good idea I think.

Yes, with your help to support the backporting efforts to the LTS branch for your needs we can make this plan.

@jamesobutler:

For supporting an LTS branch, I think providing clean and separate commits for such changes on the main branch is the best approach, if feasible. This makes it easier to cherry-pick commits from the main branch for an LTS branch. E.g., not intermingle support for Python 3.15 with cmake build system in same commit.

Yes, that is something we practice in all the repos related to 3D Slicer. MeVisLab devs can aim to commit to the same if they don't already. Then in the year 2041 or 2042, you can switch to the new branch that is Qt6 only and CMake build system only. Though at that point in time, who knows what type of dev tools we will have to support maintenance activities. This may not be something you have to worry about it since you are using the existing code pretty much without modifications for the next 16 years.

I also think it would be a best practice approach to pick LTS distributions for basing support need on. Basically, keep in the testing matrix those Python and Qt versions which are provided by the LTS releases by Red Hat and let's say Ubuntu. Thus there would/should be no need unless requested to support other Qt and Python 3 versions than those which are long-term-supported by the platform vendor themselves. I.e., a PythonQt LTS branch should build and pass test suites on RHEL and Ubuntu LTS platforms in active vendor support window. E.g., there should be no need to support Python 3.x versions on RHEL 10 which are not supported by RH themselves on RHEL 10.

https://endoflife.date/rhel

https://endoflife.date/ubuntu

@jamesobutler: I expect to be retired by 2041 :-) but I do need to keep the 40-80 year lifespan of the software under consideration for future generations of developers. The move-fast-and-break-things crew underestimate the lifespan and support window of scientific/production-use software. (We are still using and supporting scientific libraries from the 70s/80s as the science has not changed and thus the library does not need to be rewritten potentially introducing new errors.)

Yes, for us we are trying to solve "today's problems today" so staying on latest tooling, libraries (e.g. Qt6), operating systems (Win11, macOS 26, etc) are critical and expected of our customers in the scientific and medical imaging space. We can keep an LTS, but it appears our group and MeVisLab will aim to solve development issues we run into in the near term.

@jamesobutler: Good you have customers which upgrade. I have seen MRI machines still running Windows 2000 this year. :-)

Yes, we have customers with CT, Ultrasound and Optical imaging instruments switching from Windows 10 to Windows 11 based on Windows 10 no longer receiving security updates and otherwise not allowed for use at their institution.

We have software which would take 20-30 years to rewrite thus it will never be funded, happen, or even work out as imagine a 30-year project being successful. Thus it is patching and supporting old software and systems to keep going forever which is the way. Security is less of an issue as nothing is exposed directly to the Internet and RH does still provide security support for RHEL 7. Managed to get all systems off RHEL 6 about two years ago and get them moved to RHEL 7. Those systems might be ported and able to be moved to RHEL 9 in about 3-4 years but that may be too optimistic. Tendency is to be able to move to a new platform when that platform is already approaching EOL. (It takes about 5-10 years to do the porting, testing, and acceptance.)

Luckily we do not need to support Windows nor macOS with their brief support windows. We shifted from Solaris to Linux 20 years ago; and from VMS to Solaris some decades before that. Still using scientific libraries originally written for VMS in Fortran 77.

Moving some (20%, thus not yet all) scientific visualization from Motif to Qt took 15 years. Though the lion share of visualization still running on Motif and will continue to do so for a decade or longer. A major issue being RHEL 10 dropping Motif support so RHEL 9 might be in use for a very long time (beyond EOL).

The benefit of moving from Motif to Qt and thanks to PythonQt, embedded scripting (extensions) could move from a bespoke scripting language to Python. Python then also enabling extensions and interchange of data with Obspy and the Python scientific code community. (Young, <50yo) Scientists also do/know more Python these days than C/C++ for writing extensions.

For @he-hesce's use case it seems like creating a 4.0 branch to serve as an LTS for over a decade of support seems reasonable.

We can always create a maintenance branch from a tag, as soon as the need arrives to back-port something. From my experience, this is rarely needed for small projects like this one, and we can decide how to do it when needed. Declaring an official LTS may be overkill given the size of the user base.

a stable LTS branch would best be supported by ensuring newer Qt 6.x and Python 3.x releases are working (while not breaking older releases)

Up to a point. As we have ditched Python 2 support, we will probably not support some older Python and Qt versions in the future - that depends on the kind of changes needed for newer versions. Planning ahead 10 years is generally way to ambitious for me for any project (especially small ones) 😀

I think providing clean and separate commits for such changes on the main branch is the best approach

Yes, I think this is our common approach here.

We can keep an LTS, but it appears our group and MeVisLab will aim to solve development issues we run into in the near term.

Exactly.

I have seen MRI machines still running Windows 2000 this year. :-)

I can readily believe this. I was involved in making a patch release for software running under Windows 2000 a few years ago - in a VM with W2K, 4GB HD and 64MB RAM, that was really fun... I have also seen crashed ATMs showing the Windows NT 4 panic screen not so long ago.